Some comments:

• JrdResponse() should be initiated within Core, with the right $subject. The main reason is that it is cleaner, as subject IS always the value of the param resource and resource is mandatory in the request. The other reason is that someone, one day, will have his app working perfectly without initiating himself the $subject because another app is already doing it. And that app will become dependent of that other app.

• the response to the client should not contains empty entries:

  "expires": null,
  "aliases": [],
  "properties": [],

• In the tests, you are initiating a JrdResponse()with the subject 'webfinger'. webfinger is the service, not the subject.

• We should define a const somewhere with the value of a resource that will be used to retrieve local services running on the Nextcloud. A simple one one I have is mind is http://nextcloud.com/:

curl -X GET "https://cloud.example.net/.well-known/webfinger?resource=http://nextcloud.com/"
{
  "subject": "http://nextcloud.com/",
  "links": [
    {
      "rel": "https://apps.nextcloud.com/apps/circles",
      "type": "application/json",
      "href": "https://cloud.example.net/index.php/apps/circles/",
      "properties": {
        "app": "circles",
        "name": "Circles",
        "version": "21.1.2"
      }
    }
  ]
}

• The RFC also speaks about having the param rel within the request (https://tools.ietf.org/html/rfc7033#section-4.3). Now, again, might be nice to have the filter in the Core, instead of asking each app to implement a check on the param rel. The real blocker is that I don't think IRequest manage multiple identical parameter in a GET request:
  The "rel" parameter MAY be included multiple times in order to request multiple link relation types.

JrdResponse() should be initiated within Core, with the right $subject. The main reason is that it is cleaner, as subject IS always the value of the param resource and resource is mandatory in the request. The other reason is that someone, one day, will have his app working perfectly without initiating himself the $subject because another app is already doing it. And that app will become dependent of that other app.

We can initialize it. Again, that puts us into the mindset that it's all just about webfinger, which isn't the case. But it's an acceptable tradeoff that we can revert later without breaking the API. I'll pass it 👍.

the response to the client should not contains empty entries:

• https://tools.ietf.org/html/rfc7033#section-4.4.2 "an array of zero or more" for alias
• https://tools.ietf.org/html/rfc7033#section-4.4.3 "object comprises zero or more name/value pairs" for properties

We should define a const somewhere with the value of a resource that will be used to retrieve local services running on the Nextcloud. A simple one one I have is mind is http://nextcloud.com/

What do we need this for any do we need this for the API design? Sounds like a nice to have and certainly doable in a follow-up.

The RFC also speaks about having the param rel within the request (https://tools.ietf.org/html/rfc7033#section-4.3). Now, again, might be nice to have the filter in the Core, instead of asking each app to implement a check on the param rel. The real blocker is that I don't think IRequest manage multiple identical parameter in a GET request

That is what the RFC says, but it's a complex topic. There is no standard that defines how those parameters should look like in the URL. That might explain why our request object currently doesn't handle them. See https://stackoverflow.com/a/24728298/2239067 and the linked documents.

Still have issue with the getParam(), but it seems to be local. I will try tonight on a fresh install from master, and not a patched nc21beta1. Subject is not initiated here, because of this issue, but the code looks good enough.

The RFC 6415 seems to ask for XRD for host-meta, not sure we want to implement this today and just keep host-meta.json for a first merge ?

The rest looks good.

Still have issue with the getParam(), but it seems to be local. I will try tonight on a fresh install from master, and not a patched nc21beta1. Subject is not initiated here, because of this issue, but the code looks good enough.

Sounds good. We can address this independent of this new API PR. A bugfix is always easy to get in and also backported.

The RFC 6415 seems to ask for XRD for host-meta, not sure we want to implement this today and just keep host-meta.json for a first merge ?

Where is the current host-meta(.json)? I couldn't find it.

We can add an XrdResponse if necessary. Alternatively the host-meta handlers can already return a GenericResponse that wraps a custom \OCP\AppFramework\Http\Response that renders the XRD format.

The open items can be addressed in follow-ups (in 22). I'm merging this so we get the basic API in.